Authentic8 Blog Author: Guest Contributor

Authentic8 welcomes suggestions and submissions from guest contributors. Blog posts should be relevant, non-promotional and add valuable and actionable insights for improving IT security on the web.

JavaScript: How NPM Maintainer Accounts Amplify Risk

20 compromised JavaScript package “maintainer” accounts - that’s all it takes to bring down the global digital supply chain through malicious code executed in the browser.

*

Attackers need to target only 20 specific maintainer accounts to reach more than half of the entire JavaScript npm ecosystem, security researchers warn. With regular browsers on the receiving end, ready to indiscriminately execute code from affected web pages, this can trigger a disastrous chain reaction.

More than 800,000 free and reusable software packages are available through the npm (“node package manager”) software package registry. Should an attacker breach one of these at-risk accounts, it could bring down the digital supply chain worldwide, the findings of the Technical University of Darmstadt (TU Darmstadt) in Germany indicate.

In their report for Usenix, Small World with High Risks: A Study of Security Threats in the npm Ecosystem, Markus Zimmermann, Cristian-Alexandru Staicu, Cam Tenny, and Michael Pradel shine a light on the widespread use of npm packages

How to Secure Your Content Management System (CMS)

By Derek Handova

Content management systems present attractive targets for cybercriminals and state-sponsored adversaries. E-commerce sites, investor relations pages, and HR portals are just three examples where CMS vulnerabilities can cause severe reputational and financial harm.

The CMS offers multiple attack surfaces for targeting commercial or public sector entities. How can IT, administrators, creative personnel, and developers ensure CMS security?

*

In 2018 alone, more than 18 million CMS users suffered security breaches. 73.2 percent of well-known websites managed with WordPress, the most widely used CMS, contained vulnerabilities exploitable through common attacks.

Which security approaches would effectively protect CMS owners, their network, their business, and their customers? To answer this question, we have to confront the issue that many data breach vulnerabilities lie within the surface layer of the websites themselves.

There, threat actors can insert malicious code without website owners even knowing about it. For example, RiskIQ recently reported that JavaScript vulnerabilities in CloudCMS and Picreel web service scripts allowed the

Browser Security: Code Injections

In a new report titled Malicious Injections: The Tip of the Spear for Browser Threats, researchers with security firm RiskIQ predict that browser-based attacks will be a significant portion of the threat landscape for years to come, and will continue to cause major problems.

What do these attacks all have in common? Malicious injects targeting locally installed browsers. “Internet browsers are proving an invaluable attack vector for criminals,” the report concludes.

The point of injecting malicious scripts is to have the local browser dutifully execute code on the user’s machine. Attackers aim either to inject a piece of script into a web page directly or to inject a remote script (resources) into the page.

The report documents the top six techniques that they use to achieve either direct and remote injects:

Tacking it On

This is the most common method of adding malicious code to a page and can be done by injecting a malicious script in a <script>

Browser Security: What's Up with WASM?

WebAssembly, a newer type of “low-level” code that can be run by modern web browsers, is aimed at improving the web experience. The catch: Regular browsers execute such code locally. WebAssembly - merely a faster way for web-borne exploits to reach the local browser?

*

WebAssembly (WASM) is currently supported by major browsers including Firefox, Chrome, WebKit/Safari, and Microsoft Edge. Because the browser is running the WebAssembly code locally, any problems with that code also end up on the user’s machine and potentially pose a threat to the local IT environment.

How does WebAssembly work? WASM is not a high-level language. It is a way for language compilers (like those that read C, C++, and Rust high-level code) to express their assembly-level output in a different format. This output then can be directly executed by the browser.

Source: LogRocket Blog

By itself, WebAssembly code isn’t supposed to be able to do anything. It’s run inside a sandboxed virtual machine.

10 Top Tools for Threat Hunters from Black Hat USA 2018

You weren't able to make it to Las Vegas this year? Check out these ten short reviews of useful tools for threat intelligence researchers and threat hunters presented at Black Hat USA 2018:

Xori: Automated Disassembly

Black Hat USA 2018: 10 Top Tools - Xori

Malware disassembly can be quite tedious, even with a bells-and-whistles IDA Pro license. If only there was a way to automate all of it. That’s where Xori comes in.

Amanda Rousseau and Rich Seymour created a new automated disassembly platform that’s not only free, but fast. Reverse engineers often come across dozens of sample variants from the same family of malware. Having the ability to dissect all the assembly code and tell the results apart, automated and at a fast pace is something need in their arsenal of tools.

There are two modes in Xori, light and full emulation. Light emulation enumerates all the paths in CPU registers, the stack, and you’ll see some instructions. Full emulation follows the code’s path (shows