Microsoft has released an open-source tool called Counterfit that helps developers test the security of artificial intelligence (AI) systems.Microsoft has published the Counterfit project on GitHub and points out that a previous study it conducted found most organizations lack the tools to address adversarial machine learning. 

Artificial Intelligence

“This tool was born out of our own need to assess Microsoft’s AI systems for vulnerabilities with the goal of proactively securing AI services, in accordance with Microsoft’s responsible AI principles and Responsible AI Strategy in Engineering (RAISE) initiative,” Microsoft says in a blogpost. SEE: Building the bionic brain (free PDF) (TechRepublic)Microsoft describes the command line tool as a “generic automation tool to attack multiple AI systems at scale” that Microsoft’s red team operations use to test its own AI models. Microsoft is also exploring using Counterfit in the AI development phase. The tool can be deployed via Azure Shell from a browser or installed locally in an Anaconda Python environment. Microsoft promises the command line tool can assess models hosted in any cloud environment, on-premises, or on edge networks. Counterfit is also model-agnostic and strives to be data-agnostic, applicable to models that use text, images, or generic input. 

“Our tool makes published attack algorithms accessible to the security community and helps to provide an extensible interface from which to build, manage, and launch attacks on AI models,” Microsoft notes. This tool in part could be used to prevent adversarial machine learning, where an attacker tricks a machine-learning model with manipulative data, such as McAfee’s hack on older Tesla’s with MobileEye cameras, which tricked them into misreading the speed limit by placing black tape on speed signs. Another example was Microsoft’s Tay chatbot disaster, which saw the bot tweeting racist comments.      Its workflow has also been designed in line with widely used cybersecurity frameworks, such as Metasploit or PowerShell Empire. “The tool comes preloaded with published attack algorithms that can be used to bootstrap red team operations to evade and steal AI models,” explains Microsoft. The tool can also help with vulnerability scanning AI systems and creating logs to record attacks against a target model. SEE: Facial recognition: Don’t use it to snoop on how staff are feeling, says watchdogMicrosoft tested Counterfit with several customers, including aerospace giant Airbus, a Microsoft customer developing an AI platform on Azure AI services.  “AI is increasingly used in industry; it is vital to look ahead to securing this technology particularly to understand where feature space attacks can be realized in the problem space,” said Matilda Rhode, a senior cybersecurity researcher at Airbus in a statement.  “The release of open-source tools from an organization such as Microsoft for security practitioners to evaluate the security of AI systems is both welcome and a clear indication that the industry is taking this problem seriously.” More

Chances are unless you’re a JavaScript programmer, you’ve never heard of the open-source Javascript libraries ‘colors.js’ and ‘faker.js.” They’re simple programs that respectively let you use colored text on your node.js, a popular JavaScript runtime, console, and create fake data for testing. Faker.js is used with more than 2,500 other Node Package Manager (NPM) programs and is downloaded 2.4 million times per week. Colors.js is built into almost 19,000 other NPM packages and is downloaded 23 million times a week. In short, they’re everywhere. And, when their creator, JavaScript developer Marak Squires, fouled them up, tens of thousands of JavaScript programs blew up.

Thanks, guy.This isn’t the first time a developer deliberately sabotaged their own open-source code. Back in 2016, Azer Koçulu deleted a 17-line npm package called ‘left-pad, ‘which killed thousands of Node.js programs that relied on it to function. Both then and now the actual code was trivial, but because it’s used in so many other programs its effects were far greater than users would ever have expected.  Why did Squires do it? We don’t really know. In faker.js’s GitHub README file, Squires said, “What really happened with Aaron Swartz?” This is a reference to hacker activist Aaron Swartz who committed suicide in 2013 when he faced criminal charges for allegedly trying to make MIT academic journal articles public.Your guess is as good as mine as to what this has to do with anything.What’s more likely to be the reason behind his putting an infinite loop into his libraries is that he wanted money. In a since-deleted GitHub post, Squires said, “Respectfully, I am no longer going to support Fortune 500s ( and other smaller-sized companies ) with my free work. There isn’t much else to say. Take this as an opportunity to send me a six-figure yearly contract or fork the project and have someone else work on it.”Excuse me. While open-source developers should be fairly compensated for their work, wrecking your code isn’t the way to persuade others to pay you. 

This is a black eye for open-source and its developers. We don’t need programmers who crap on their work when they’re ticked off at the world.Another problem behind the problem is that too many developers simply automatically download and deploy code without ever looking at it. This kind of deliberate blindness is just asking for trouble. Just because a software package was made by an open-source programmer doesn’t mean that it’s flawless. Open-source developers make as many mistakes as any other kind of programmer. It’s just that in open source’s case, you have the opportunity to check it out first for problems. If you choose to not look before you deploy, what happens next is on you.

Some criminal developers are already using people’s blind trust to sneak malware into their programs. For example, the DevOps security firm JFrog recently discovered 17 new JavaScript malicious packages in the NPM repository that deliberately attack and steal a user’s Discord tokens. These can then be used on the Discord communications and digital distribution platform.Is that a lot of work? You bet it is. But, there are tools such as NPM audit, GitHub’s DependendaBot, and OWASP Dependency-Check that can help make it easier. In addition, you can simply make sure that before any code goes into production, you simply run a sanity check on it in your continuous integration/continuous distribution (CI/CD) before deploying it to production. I mean, seriously, if you’d simply run either of these libraries in the lab they would have blown up during testing and never, ever make it into the real world. It’s not that hard!In the meantime, GitHub suggests you revert back to older, safer versions. To be exact, that’s colors.js 1.40 and faker.js 5.5.3. As CodeNotary, a software supply chain company, pointed out in a recent blog post, “Software is never complete and the code base including its dependencies is an always updating document. That automatically means you need to track it, good and bad, keeping in mind that something good can turn bad.” Exactly!Therefore, they continued, “The only real solution here is to be on top of the dependency usage and deployment. Software Bill of Materials (SBOMs) can be a solution to that issue, but they need to be tamper-proof, queryable in a fast and scalable manner, and versioned.CodeNotary suggests, of course, you use their software, Codenotary Cloud and the vcn command-line tool, for this job. There are other companies and projects that address SBOM as well. If you want to stay safe, moving forward you must — I repeat must — use an SBOM. Supply chain attacks, both from within projects and without, are rapidly becoming one of the main security problems of our day.Related Stories: More

Image: Nedbank Nedbank, one of the biggest banks in the South Africa region, has disclosed a security incident yesterday that impacted the personal details of 1.7 million users. The bank says the breach occurred at Computer Facilities (Pty) Ltd, a South African company the bank was using to send out marketing and promotional campaigns. In […] More

Image: Getty/damircudic A cruel business email compromise (BEC) gang is hacking people’s email accounts and sending messages to their contacts claiming the account owner needs to send a gift to an unwell friend in an attempt to manipulate people into sending online gift cards.  ZDNET Recommends Detailed by cybersecurity researchers at Abnormal Security, an organized […] More

For those unable to patch the Apache Log4Shell vulnerability, cybersecurity firm Cybereason has released what they called a “fix” for the 0-day exploit. Cybereason urged people to patch their systems as soon as possible, but for those who cannot update their systems or do so immediately, they have created a tool they are calling “Logout4shell.”

Log4j coverage

It is freely available on GitHub and Cybereason said it “is a relatively simple fix that requires only basic Java skills to implement.” “In short, the fix uses the vulnerability itself to set the flag that turns it off. Because the vulnerability is so easy to exploit and so ubiquitous—it’s one of the very few ways to close it in certain scenarios,” said Yonatan Striem-Amit, CTO of Cybereason. “You can permanently close the vulnerability by causing the server to save a configuration file, but that is a more difficult proposition. The simplest solution is to set up a server that will download and then run a class that changes the server’s configuration to not load things anymore.”The “vaccine” garnered a mixed response from experts, some of whom praised the company for stepping up while others said it wasn’t nearly enough to protect those affected by the vulnerability. Dr. Richard Ford, CTO of Praetorian, said the Log4j vulnerability can be subtle, and while it is sometimes revealed with simple scanning, it is also frequently found buried deep in customer infrastructure, where it can be trickier to trigger. “For this reason, I am concerned that some of the well-meaning responses I’ve seen from the industry can cause longer-term problems. In the case of Logout4Shell, it’s not always as trivial to exploit as entering a simple string into ‘a vulnerable field.’ Knowing which field is vulnerable can be tricky, and with many folks now filtering traffic en route knowing your string even reached the server intact is not trivial,” Ford explained.

“If we inadvertently give a customer the impression that just popping ${$jnfi… into a string is good enough, folks could end up with a false sense of security. In addition, generically patching a server could have unpleasant unintended consequences, and it’s up to customers to figure out what risks they can tolerate in a production system. Cybereason’s tool is an interesting approach, but would not recommend a customer solely rely on it.”Randori’s Aaron Portnoy said hot patching solutions such as this can be effective stop-gap mitigations, but this solution will only be effective for the lifetime of the Java Virtual Machine. “If the application or the system restart, the ‘vaccine’ would need to be re-applied. The best remediation is to upgrade the log4j2 library and apply default-deny firewall rules on outbound traffic for systems that may be susceptible,” Portnoy said. Bugcrowd CTO Casey Ellis noted that to run this without permission on someone else’s infrastructure “is almost certainly in violation of anti-hacking laws like the CFAA, which creates legal risk regardless of whether the intent is benevolent or malicious.” “While folks may be well-intentioned, it’s important for them to understand the legal risk it creates for them. It’s a similar technique to what the FBI and DOJ did earlier in the year to mitigate HAFNIUM web shells on Exchange servers, only the FBI had the legal blessing of the DOJ,” Ellis said. “Aside from that, I quite like the ‘chaotic good’ nature of this solution – especially given the chaos organizations are experiencing in finding all of the places that log4j might exist within their environment. The script basically takes the workaround first flagged by Marcus Hutchins which disables indexing and then uses the vulnerability itself to apply it. The fact that solutions like this are coming out so quickly is telling regarding the ubiquity of this vulnerability, the complexities of applying a proper patch, and the sheer number of ways that it can be exploited.”Ellis added that the tool’s effectiveness is limited because it does not work for versions prior to 2.10, requires a restart, and the exploit must fire properly in order to be effective. Even when it does run properly, it still leaves the vulnerable code in place, Ellis explained. Because of the complexity of regression testing Log4j, Ellis said he already heard from a number of organizations that are pursuing the workarounds contained in the Cybereason tool as their primary approach. He expects at least some to use the tool selectively and situationally but said it is critical to understand that this isn’t a solution – it’s a workaround with a number of limitations. “It has intriguing potential as a tool in the toolbox as organizations reduce log4j risk, and if it makes sense for them to use it, one of the primary reasons will be speed to risk reduction,” Ellis said.  More