Thirty years ago today, Netscape Communications and Sun Microsystems issued a joint press release announcing JavaScript, an object scripting language designed for creating interactive web applications. The language emerged from a frantic 10-day sprint at pioneering browser company Netscape, where engineer Brendan Eich hacked together a working internal prototype during May 1995.

While the JavaScript language didn’t ship publicly until that September and didn’t reach a 1.0 release until March 1996, the descendants of Eich’s initial 10-day hack now run on approximately 98.9 percent of all websites with client-side code, making JavaScript the dominant programming language of the web. It’s wildly popular; beyond the browser, JavaScript powers server backends, mobile apps, desktop software, and even some embedded systems. According to several surveys, JavaScript consistently ranks among the most widely used programming languages in the world.

In crafting JavaScript, Netscape wanted a scripting language that could make webpages interactive, something lightweight that would appeal to web designers and non-professional programmers. Eich drew from several influences: The syntax looked like a trendy new programming language called Java to satisfy Netscape management, but its guts borrowed concepts from Scheme, a language Eich admired, and Self, which contributed JavaScript’s prototype-based object model.

Read full article

Comments

© Netscape / Benj Edwards

Security and developer teams are scrambling to address a highly critical security flaw in frameworks tied to the popular React JavaScript library. Not only is the vulnerability, which also is in the Next.js framework, easy to exploit, but React is widely used, including in 39% of cloud environments.

The post Dangerous RCE Flaw in React, Next.js Threatens Cloud Environments, Apps appeared first on Security Boulevard.

This attempt to phish credentials caught our attention, mostly because of its front-end simplicity. Even though this is a script-kiddie-level type of attack, we figured it was worth writing up—precisely because it’s so easy to follow what they’re up to.

The email is direct and to the point. Not a lot of social engineering happening here.

“Dear ,

Pls kindly find the attached PO please send us PI once its available.”

The sender’s address belongs to a Czechoslovakian printing service (likely compromised), and the name and phone number are fake. The target is in Taiwan.

The attached .shtml file is a tidy fake login screen that doesn’t really specify which credentials they want:

The pre-filled email address in the screenshot is a fake one I added; normally it would be the target’s email.

We assume the phisher welcomes any credentials entered here, and are counting on the fact that most people reuse passwords on other sites.

Under the hood, the functionality of this attachment lies in this piece of JavaScript.

It starts with simple checks to make sure all the fields are filled out and long enough before declaring the Telegram bot that will receive the login details.

Using Telegram bots provides the phishers with several advantages:

• Stolen credentials are delivered instantly to the attacker via Telegram notifications. No need for the phisher to keep checking a database or inbox.
• Telegram is a legitimate, globally distributed messaging service, making it difficult to block.
• There’s no exposed web server or obvious phishing “drop site” that can be blocklisted or shut down.

The last line contains a credibility trick:

setTimeout(() => {window.location.assign("file:///C:/Users/USER/Downloads/Invoice_FAC_0031.pdf")}, 2000);

This tries to open a file on the user’s computer after waiting 2 seconds (2,000 milliseconds). Since this file almost certainly doesn’t exist, the browser will either block the action (especially from an email or non-local file) or show an error. Either way, it will make the login attempt look more legitimate and take the user’s mind off the fact that they just sent their credentials who knows where.

That’s really all there is to it, except for a bit of code that the dungeon-dweller forgot to remove during their copy-and-paste coding. Or they had no idea what it was for and left it in place for fear of breaking something.

I suspect the attacker originally used this code to encrypt the credentials with a hardcoded AES (Advanced Encryption Standard) key and injection vector, then send them to their server.

This attacker replaced that method with the simpler Telegram bot approach (much easier to use), but left the decryption stub because they were afraid removing it would break something.

Don’t fall for phishing attempts

Even though the sophistication level of this email was low, that does not reduce the possible impact of sending the attacker your credentials.

In phishing attempts like these, two simple rules can save you from lots of trouble.

• Don’t open unsolicited attachments
• Check if the website address in the browser matches the domain you expect to be on (e.g. adobe.com).

Other important tips to stay safe from phishing in general:

• Verify the sender: Always check if the sender’s email address matches what you would expect it to be. It’s not always conclusive but it can help you spot some attempts.
• Check through an independent channel if the sender actually sent you an attachment or a link.
• Use up-to-date security software, preferably with a web protection component.
• Keep your device and all its software updated.
• Use multi-factor authentication for every account you can.
• Use a password manager. Password managers will not auto-fill a password to a fake site, even if it looks like the real deal to you.

If you already entered credentials on a page you don’t trust, change your passwords immediately.

Pro tip: You can also upload screenshots of suspicious emails to Malwarebytes Scam Guard. It would have recognized this one as a phishing attempt.

---

We don’t just report on scams—we help detect them

Cybersecurity risks should never spread beyond a headline. If something looks dodgy to you, check if it’s a scam using Malwarebytes Scam Guard, a feature of our mobile protection products. Submit a screenshot, paste suspicious content, or share a text or phone number, and we’ll tell you if it’s a scam or legit. Download Malwarebytes Mobile Security for iOS or Android and try it today!

At least 18 popular JavaScript code packages that are collectively downloaded more than two billion times each week were briefly compromised with malicious software today, after a developer involved in maintaining the projects was phished. The attack appears to have been quickly contained and was narrowly focused on stealing cryptocurrency. But experts warn that a similar attack with a slightly more nefarious payload could lead to a disruptive malware outbreak that is far more difficult to detect and restrain.

Aikido is a security firm in Belgium that monitors new code updates to major open-source code repositories, scanning any code updates for suspicious and malicious code. In a blog post published today, Aikido said its systems found malicious code had been added to at least 18 widely-used code libraries available on NPM (short for) “Node Package Manager,” which acts as a central hub for JavaScript development and the latest updates to widely-used JavaScript components.

JavaScript is a powerful web-based scripting language used by countless websites to build a more interactive experience with users, such as entering data into a form. But there’s no need for each website developer to build a program from scratch for entering data into a form when they can just reuse already existing packages of code at NPM that are specifically designed for that purpose.

Unfortunately, if cybercriminals manage to phish NPM credentials from developers, they can introduce malicious code that allows attackers to fundamentally control what people see in their web browser when they visit a website that uses one of the affected code libraries.

According to Aikido, the attackers injected a piece of code that silently intercepts cryptocurrency activity in the browser, “manipulates wallet interactions, and rewrites payment destinations so that funds and approvals are redirected to attacker-controlled accounts without any obvious signs to the user.”

“This malware is essentially a browser-based interceptor that hijacks both network traffic and application APIs,” Aikido researcher Charlie Eriksen wrote. “What makes it dangerous is that it operates at multiple layers: Altering content shown on websites, tampering with API calls, and manipulating what users’ apps believe they are signing. Even if the interface looks correct, the underlying transaction can be redirected in the background.”

Aikido said it used the social network Bsky to notify the affected developer, Josh Junon, who quickly replied that he was aware of having just been phished. The phishing email that Junon fell for was part of a larger campaign that spoofed NPM and told recipients they were required to update their two-factor authentication (2FA) credentials. The phishing site mimicked NPM’s login page, and intercepted Junon’s credentials and 2FA token. Once logged in, the phishers then changed the email address on file for Junon’s NPM account, temporarily locking him out.

Junon also issued a mea culpa on HackerNews, telling the community’s coder-heavy readership, “Hi, yep I got pwned.”

“It looks and feels a bit like a targeted attack,” Junon wrote. “Sorry everyone, very embarrassing.”

Philippe Caturegli, “chief hacking officer” at the security consultancy Seralys, observed that the attackers appear to have registered their spoofed website — npmjs[.]help — just two days before sending the phishing email. The spoofed website used services from dnsexit[.]com, a “dynamic DNS” company that also offers “100% free” domain names that can instantly be pointed at any IP address controlled by the user.

Caturegli said it’s remarkable that the attackers in this case were not more ambitious or malicious with their code modifications.

“The crazy part is they compromised billions of websites and apps just to target a couple of cryptocurrency things,” he said. “This was a supply chain attack, and it could easily have been something much worse than crypto harvesting.”

Aikido’s Eriksen agreed, saying countless websites dodged a bullet because this incident was handled in a matter of hours. As an example of how these supply-chain attacks can escalate quickly, Eriksen pointed to another compromise of an NPM developer in late August that added malware to “nx,” an open-source code development toolkit with as many as six million weekly downloads.

In the nx compromise, the attackers introduced code that scoured the user’s device for authentication tokens from programmer destinations like GitHub and NPM, as well as SSH and API keys. But instead of sending those stolen credentials to a central server controlled by the attackers, the malicious code created a new public repository in the victim’s GitHub account, and published the stolen data there for all the world to see and download.

Eriksen said coding platforms like GitHub and NPM should be doing more to ensure that any new code commits for broadly-used packages require a higher level of attestation that confirms the code in question was in fact submitted by the person who owns the account, and not just by that person’s account.

“More popular packages should require attestation that it came through trusted provenance and not just randomly from some location on the Internet,” Eriksen said. “Where does the package get uploaded from, by GitHub in response to a new pull request into the main branch, or somewhere else? In this case, they didn’t compromise the target’s GitHub account. They didn’t touch that. They just uploaded a modified version that didn’t come where it’s expected to come from.”

Eriksen said code repository compromises can be devastating for developers, many of whom end up abandoning their projects entirely after such an incident.

“It’s unfortunate because one thing we’ve seen is people have their projects get compromised and they say, ‘You know what, I don’t have the energy for this and I’m just going to deprecate the whole package,'” Eriksen said.

Kevin Beaumont, a frequently quoted security expert who writes about security incidents at the blog doublepulsar.com, has been following this story closely today in frequent updates to his account on Mastodon. Beaumont said the incident is a reminder that much of the planet still depends on code that is ultimately maintained by an exceedingly small number of people who are mostly overburdened and under-resourced.

“For about the past 15 years every business has been developing apps by pulling in 178 interconnected libraries written by 24 people in a shed in Skegness,” Beaumont wrote on Mastodon. “For about the past 2 years orgs have been buying AI vibe coding tools, where some exec screams ‘make online shop’ into a computer and 389 libraries are added and an app is farted out. The output = if you want to own the world’s companies, just phish one guy in Skegness.”

Aikido recently launched a product that aims to help development teams ensure that every code library used is checked for malware before it can be used or installed. Nicholas Weaver, a researcher with the International Computer Science Institute, a nonprofit in Berkeley, Calif., said Aikido’s new offering exists because many organizations are still one successful phishing attack away from a supply-chain nightmare.

Weaver said these types of supply-chain compromises will continue as long as people responsible for maintaining widely-used code continue to rely on phishable forms of 2FA.

“NPM should only support phish-proof authentication,” Weaver said, referring to physical security keys that are phish-proof — meaning that even if phishers manage to steal your username and password, they still can’t log in to your account without also possessing that physical key.

“All critical infrastructure needs to use phish-proof 2FA, and given the dependencies in modern software, archives such as NPM are absolutely critical infrastructure,” Weaver said. “That NPM does not require that all contributor accounts use security keys or similar 2FA methods should be considered negligence.”