New analysis shows attackers for the most part are continuing to rely on the same techniques and tactics they have been using for years.

Despite the intimidating nature of the threat landscape, organizations can achieve considerable defense in depth by monitoring a relatively small number of data sources and keeping an eye out for a handful of malicious patterns in the data.

In fact, much of the information required to detect most commonly encountered threats and malicious techniques can be drawn right from Windows event logs and systems monitoring, according to a new report by security vendor Red Canary.

Researchers from the company analyzed data related to 20,000 confirmed threats detected across Red Canary customer networks last year and mapped the data to the different attack techniques and sub-techniques described in MITRE’s widely used ATT&CK framework. The report offers a comprehensive overview of each of the most widely used techniques and threats, with guidance on how attackers are using them and how to spot the activity.

The analysis shows attackers for the most part are continuing to rely on the same techniques and tactics they have been using for years. And, despite all the concern about sophisticated advanced persistent threat (APT) actors and related threats, the most common threats that organizations encountered last year are what some would classify as commodity malware.

“Although the threat landscape can be overwhelming, there are many opportunities we have as defenders to catch threats in [our] networks,” says Katie Nickels, director of intelligence at Red Canary. “The challenge for defenders is to balance the ‘tried and true’ detection opportunities that adversaries reuse with keeping an eye on new techniques and threats.”

Red Canary’s analysis shows attackers most commonly abused command and script interpreters like PowerShell and Windows Command Shell to execute commands, scripts, and binaries. Nearly half (48.7%) of the organizations in the dataset encountered threats involving the use of PowerShell, and 38.4% had to deal with threats involving the abuse of Windows Command Shell. Attackers most commonly took advantage of PowerShell’s interactive command-line interface and scripting features to execute malicious commands, obfuscate malware, and malicious activity to download additional payloads and spawn additional processes. Logs such as Anti-Malware Scan Interface (AMSI), scriptblock, or Sysmon can be especially helpful in detecting PowerShell abuse, Red Canary says in its report.

The second mostly commonly detected attack technique was signed binary process execution, an attack method where digitally signed, trusted binaries such as Rundll32 and Mshta are used to bypass signature and behavior-based detection tools. Rundll32, an essential native Windows process installed by default on Windows systems since Windows 95, was most commonly abused to execute malicious code as a Dynamic Link Library. Cybercriminals also used it to carry out other activities, such as dumping the memory of certain processes and retrieving cached credentials, Red Canary says.

Meanwhile, attackers primarily used the Mshta binary to execute arbitrary VBScript and JScript files. Monitoring process command-line parameters and process monitoring are both useful for detecting malicious execution of Rundll32, Red Canary said.

Rounding out the list of top five techniques that Red Canary detected last year were creating and modifying system processes, scheduling tasks/jobs, and credential dumping.

Red Canary researchers observed attackers typically creating and modifying system processes such as Windows services to achieve persistence on a compromised system and to leverage elevated privileges. They also frequently used the “Scheduled Task” task-scheduling feature in Windows to maintain access and execute processes typically in the context of a privileged user. Credential dumping was a favored tactic for privilege escalation, data theft, and lateral movement.

Consistent Techniques
“The top techniques have been pretty consistently prevalent over the years,” Nickels says. “While they aren’t always in top five techniques, things like PowerShell, Scheduled Tasks, and Credential Dumping have been and remain very common.”

For organizations, one of the biggest challenges in detecting the use of these techniques is the fact that most can be used in legitimate and malicious ways.

“Techniques that tend to be ‘dual purpose’ in nature can be initially challenging to detect because each organization has to determine what is normal for them,” she says.

She advises organizations work to understand their available data sources so they can baseline what is normal in their environment and set malicious activity detection trigger accordingly.

But it is not just the techniques and tactics that are relatively easily detectable in many cases, Red Canary found. Many of the most frequently detected malware and dual-purpose tools the company observed last year were tools that organizations likely underestimate because they are considered commodity malware. Among them were Cobalt Strike, Qbot, IcedID, Mimikatz and Emotet.

One surprise entry in Red Canary’s top 10 last was USB worm Gamarue. Though the malware tool’s command-and-control infrastructure was disrupted in 2017, it still surfaces regularly on compromised environments, Nickels says.

“This highlights the importance of defenders not dismissing any threats as ‘too old’ or ‘simple,'” she notes. “We’ve seen that many ‘old’ threats have a significant impact on many organizations.”

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Recommended Reading:

More Insights

Attackers linked to North Korea began to target security researchers on social media earlier this year.

Google’s Threat Analysis Group (TAG) today shared an update on a campaign that has been targeting security researchers on social media and is attributed to the North Korean government. 

The campaign, disclosed in January, targeted security researchers working on vulnerability research and development across different organizations. Attackers created several types of social media profiles to chat with researchers and share videos and blogs of claimed exploits. They ultimately tried to share infected files or trick the victims into clicking a malicious link. 

In an update published today, TAG reports the same attackers behind this campaign created a new website with their associated social media profiles for a fake company called “SecuriElite.” The site claims to represent a Turkey-based offensive security firm and has a link to its PGP key, which was used in the January attacks to try and get researchers to visit a malicious website. 

The newest social media profiles shared on the fake website are designed to appear as security researchers, another tactic seen in the January attacks. TAG also identified two LinkedIn accounts posing as recruiters for antivirus and security firms, and it has reported all social profiles to the respective platforms. The new site has not been seen serving malicious content.

“Following our January blog post, security researchers successfully identified these actors using an Internet Explorer 0-day,” TAG said in today’s update. “Based on their activity, we continue to believe that these actors are dangerous, and likely have more 0-days.” 

Read the full post for more details.

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Recommended Reading:

More Insights

A technique called hooking used by most endpoint detection and response products to monitor running processes can be abused, new research shows.

A fundamental weakness in the way almost all endpoint detection and response (EDR) systems work gives attackers an opening to sneak malware past them.

Fixing the issue is not going to be easy, requiring a substantial overhaul of most current EDR systems on the market, Optiv said in a report this week.

EDR products are designed to detect and respond to suspicious behaviors and attacks on endpoint devices. Most combine signature-based malware detection with heuristic analysis, sandboxing, and other techniques to spot and block threats. The technology allows security teams to quickly isolate compromised systems and collect endpoint logs and other threat indicators to facilitate remediation.

One technique many EDR products use to detect suspicious activity and gather information for behavior-based analytics is called “hooking.” Matthew Eidelberg, technical manager at Optiv, describes hooking as a technique for monitoring computer programs as they run. The hooks are placed at a System Call (syscall) interface, which allows a running process to interact with the operating system to request services, such as allocating memory, or to create a file.

“Many EDR products place these hooks at a point of program execution that users have access to so they have permissions to remove or completely bypass them,” Eidelberg says.

The hooks give EDR agents on endpoint devices a way to monitor all running processes and look for any changes to those processes. The EDR agent passes data gathered via hooking to the EDR vendor’s platform for further analysis.

The problem is that because the hooks are placed in user space, everything in a process’ memory space when the process is created has the same permissions as the user running it.

“This means that malicious code has the same permissions as the system Dynamic Link Libraries,” Eidelberg says.

As a result, attackers can modify the hooks in these system DLLs to allow malicious code to bypass the EDR product’s detection and remediation mechanisms. Because of where the hooks exist, attackers could also write their own malicious system call functions into a process and have the operating system execute the functions.

“EDR products don’t know that these exist or where they are located, so it makes it impossible for them to hook,” Eidelberg said.

Optiv’s research into weaknesses around EDR and memory hooks builds on previous work by other researchers. But rather than focusing on techniques that work only on individual products, the security vendor looked to see whether it could find systemic issues with hooking across all EDR products that attackers could exploit, Optiv said in its report. As part of its effort, the company developed exploits showing how it could sneak a malicious payload past products from four leading EDR product vendors.

An attacker would only need access to a remote endpoint to execute these attacks, Eidelberg noted. However, EDRs that operate in the kernel space shouldn’t be as affected.

“This is because the kernel space is one area where these hooks are pretty reliable,” he says. “It’s hard for an attacker to do anything in the kernel given security controls around loading code.”

Eidelberg says Optiv has been helping EDR vendors understand how attackers can exploit these issues in the wild. Several of them have begun to revamp their products and augment the telemetry collected via hooking to see whether they can detect tampering of system DLLs, he says. Some vendors are even moving their hooks into protected kernel space.

“All of these are great steps but will take some time to implement,” he noted.

In the meantime, organizations should continue ensuring they have strong controls and detection mechanisms for preventing attackers from getting to the point where they can execute malicious code on an endpoint system in the first place, Eidelberg says.

“For an attacker to exploit this, they would need to get their malicious code onto an organization’s systems and execute these actions,” he says.

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Recommended Reading:

More Insights

You’re fully aware of the need to stop threats at the front door and then hunt any that got through that first gate, so your company installed an EPP/ EDR solution.

But like most companies, you’ve already come across its shortcoming – and these are amplified since you have a small security team. More than likely, you noticed that it has its share of detection blind spots and limitations for which you need to tack on more detection technologies.

Remediation requires manual effort, and in terms of operation, it’s become too much of an investment on your already resource-constrained staff. Deployment took you ages, so you’re somewhat wary of introducing new technology and going through that process again.

What should you do – fight for more resources, flight from the EDR/ EPP combo to other technological solutions, or freeze by accepting this painful situation and updating the board that your risk levels remain high?

When fight and freeze are typically the directions you want to avoid taking, you need to know what to expect if you do move along.

The guide “Decided to move on from your NGAV/EDR? A guide to what’s next” walks you through six steps in that transition process, so you come best prepared for that next protection level:

Step 1: Why are you moving? Before you justify to your team – and to the company – why you are transitioning, you need to justify this to yourself. According to a Cynet 2021 survey of CISOs with small security teams, the biggest pain point in operating threat protection products selected by 51% of companies, and with a significant gap of 38% from the second place, is the overlapping capabilities of disparate technologies. Following that response, in second and third place, companies suffer from operational challenges.

These are having too many dashboards (37%) and computing lag on deployed devices (36%). Are these also your main challenges? Always go back to that painful base point when evaluating your alternatives, as this is what started you off in the first place on the transition journey.

Step 2: Consider your options. Since you cannot rely solely on the EDR/ EPP stack, your alternatives boil down to two. The first, keeping your current solution and investing in compensating detection technologies to cover blind spots. On top of this, further stacking on solutions to automate investigation and other manual processes. The second, investing in an Extended Detection and Response (XDR) platform.

An XDR platform consolidates and rationalizes alerts into actionable incidents and automates investigation and response actions. XDRs include the EPP/ EDR component – but these are only components of the full breach protection platform. Go through the guide for a pros and cons list to help you decide which option you want to take, and make sure to add points to that table per your environment.

Step 3: Build the business case. Most companies with small security teams choose an XDR. An immediate question that then arises is where to get the budget for the new platform. This is where you build the business case and the guide helps you by providing three aspects to consider when allocating the budget. Make sure not to sell yourself short by reducing the budget to save costs. Rather, use the same budget to achieve more.

Step 4: List the XDR requirements. XDR technologies vary in their offerings. Some integrate more technologies than others, others are simpler to deploy and manage. Various XDRs range in levels of automation, and MDR service offerings differ as well from vendor to vendor. This is where you need to decide what are the most important XDR capabilities that suit your small security team.

As a start, you should make sure you consider the must-have four parameters and decide to which extent you’re willing to compromise – ease of deployment, types of detection technologies, level of automated breach response, and MDR augmentation offerings.

Step 5: Shortlist the XDR vendors. Now that you have the requirements, it’s time to shortlist the XDR vendors you’d like to evaluate. There are several ways to help you build this list: garner peer feedback, look at review sites, check if the vendor provides trial offerings such as a try and buy, and of course, bring cost considerations into account.

Step 6: Send out an RFP. This is an important step to assess the technology. RFPs are tedious but remember, you send out the same one to each vendor so it’s enough to create just a single copy and then the comparison of the responses is quite straight-forward. As an incredibly time-saving tip, the guide also refers to an already created RFP template for XDR protection which you’ll find relevant if you have a small security team.

Undoubtedly the EPP/ EDR combination is not enough for your small team. While they are important tools, you’re starting to feel the combination as a double edged sword – one on hand it doesn’t fully address your current needs and on the other creates a burden on your resource-constrained team. It’s time to move.

This guide serves as a companion as you go through that transition process, providing the necessary insights based on experience to help you steer clear of any road bumps.

Download the eBook Decided to move on from your NGAV/EDR? A guide to what’s next

Cybersecurity researchers on Tuesday disclosed details of a sophisticated campaign that deploys malicious backdoors for the purpose of exfiltrating information from a number of industry sectors located in Japan.

Dubbed “A41APT” by Kaspersky researchers, the findings delve into a new slew of attacks undertaken by APT10 (aka Stone Panda or Cicada) using previously undocumented malware to deliver as many as three payloads such as SodaMaster, P8RAT, and FYAnti.

The long-running intelligence-gathering operation first came into the scene in March 2019, with activities spotted as recently as November 2020, when reports emerged of Japan-linked companies being targeted by the threat actor in over 17 regions worldwide.

The fresh attacks uncovered by Kaspersky are said to have occurred in January 2021. The infection chain leverages a multi-stage attack process, with the initial intrusion happening via abuse of SSL-VPN by exploiting unpatched vulnerabilities or stolen credentials.

Center to the campaign is a malware called Ecipekac (“Cake piece” in reverse, but with a typo) that traverses a four-layer “complicated loading schema” by making use of four files to “load and decrypt four fileless loader modules one after the other to eventually load the final payload in memory.”

While the main purpose of P8RAT and SodaMaster is to download and execute payloads retrieved from an attacker-controlled server, Kaspersky’s investigation hasn’t yielded any clues as to the exact malware delivered on target Windows systems.

Interestingly, the third payload, FYAnti, is a multi-layer loader module in itself that goes through two more successive layers to deploy a final-stage remote access Trojan known as QuasarRAT (or xRAT).

“The operations and implants of the campaign … are remarkably stealthy, making it difficult to track the threat actor’s activities,” Kaspersky researcher Suguru Ishimaru said. “The main stealth features are the fileless implants, obfuscation, anti-VM ,and removal of activity tracks.”

Companies that spend the smallest share of their IT budget on security see fewer threats, but that’s not good news.

Ignorance may be bliss, but not in security.

Companies that spend less on security — as a percentage of their information technology budget — saw fewer threats in the previous year, but mainly because reduced visibility and their lack of expertise failed to find existing threats, market intelligence firm Forrester Research states in its “Global Security Budgets in 2021” report, published on March 26.

The report, based on a survey of nearly 3,700 budget decision-makers, found that about half of budgets is allocated to security products and half to services, across all levels of security spending. Among the companies that spent 0% to 10% of their IT budgets on security, however, almost half had not detected a breach in the past 12 months, compared with a quarter to a third of companies that spent more.

On its face, the data appears to be good news, but the companies are actually failing to detect attacks rather than avoiding them, says Jeff Pollard, vice president and principal analyst at Forrester Research. 

“When you dig into it and talk to organizations of that size, they don’t have the situational awareness and visibility that [those companies who spend more] have,” he says. “So, for the companies spending 0% to 10% of their budget, the issue is not spend less and get breached less, it’s spend less and fail to detect the attacks until much later.”

With the pandemic forcing companies to make significant changes to their IT infrastructure, securing increasingly cloud-based and distributed business assets will likely require more budget. Between 2019 and 2020, about 60% of companies increased their security budget, according to the Forrester Research report

Other market researchers have noticed a similar trend. The average company spent 10.9% of their IT budget on security in 2020, about $2,700 per employee on average, according to an August report by consulting firm Deloitte and the Financial Services Information Sharing and Analysis Center (FS-ISAC).

Forrester expects the pandemic to affect security organizations differently, depending on the amount spent on security: 0% to 10%, 11% to 20%, and 21% to 30% of the IT budget. The average company in the lowest tier spent 16% on security staffing, compared with 12% in the highest tier. Meanwhile, the average company in the highest tier spent 16% on cloud security, compared with 13% for companies in the lowest tier.

“For organizations in the lowest-budget tier, headcount remains the largest expense followed by the costs of maintaining and licensing on-premises technology,” according to the report. “Organizations with larger budgets tend to focus on expanding cloud security capabilities to secure disrupted business models as they accelerate the use of cloud security technologies due to the pandemic.”

The level of security maturity appears to correlate with the level of investments, especially the strategic goals of the companies at each level. The two top priorities for the lowest tier of security budget, for example, focused on establishing security in public clouds and aligning the business and security groups, while the top-two priorities in the highest security tier focused on instilling a culture of security in the company and aligning business and security groups.

Those different goals stand out, says Pollard.

“What really stood out was that, looking at the 21% to 30% bracket and seeing that … they were really thinking about creating a culture of security throughout the organization,” he says. “When you look at the differences between the different investment levels, you see a lot of focus on technologies, but it’s that focus on culture that will create a lasting change.”

Increased security budget does not necessarily correlate with fewer breaches. Instead, more budget seems to increase detection. Almost half — 49% — of the lowest security-budget tier detected no breaches in the past 12 months, compared with 31% of the highest level of security budget. Conversely, only 20% of the lowest tier detected three or more breaches in the past 12 months, compared with 43% of the companies that spent the most on security.

Yet more spending does not necessarily mean better security, says Pollard. The problem with many companies is that they lose track of security spending and pay for similar products in services in different silos. This “expense in depth” — borrowing a term used by Gartner — means that security programs are not spending efficiently.

“Security leaders are focused on both innovation and making budget more efficient,” he says. “Rationalizing budget and making sure that you are spending on the right technologies is incredibly important.”

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT’s Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline … View Full Bio

Recommended Reading:

More Insights

The United States Government Accountability Office (GAO) recently completed and published a study on electricity grid cybersecurity that concluded that the Department of Energy (DOE) needs to ensure its plans fully address risks to electricity distribution systems.

The GAO completed two prior studies of the generation and transmission functions of the electricity grid and found that they are increasingly vulnerable to cyber-attacks. The third function of the electricity grid is distribution, which was the subject matter of this study.

According to the study, the U.S. electricity grid distribution system, which comprise the conduits from electric companies to consumers, and which are regulated by states, “are increasingly at risk from cyber-attacks.” According to the study, “Distribution systems are growing more vulnerable, in part because their industrial control systems increasingly allow remote access and connect to business networks.” Therefore, they can be attacked through “multiple techniques” which can potentially disrupt operations.

The DOE has developed plans for the national cybersecurity strategy for the electricity grid. According to GAO’s study, the DOE’s plans “do not fully address risks to the grid’s distribution systems.” The GAO “recommends that DOE more fully address risks to the grid’s distribution systems from cyberattacks—including their potential impact—in its plans to implement the national cybersecurity strategy.” The DOE agreed with the recommendation and provided information on two research projects that are designed to improve the cybersecurity of distribution systems.

There are several diagrams of the risks to distribution systems in the study which are quite chilling.  The study can be accessed here.

Security researchers analyzing a widely used open source component have discovered security vulnerabilities that leave hundreds of thousands of software applications vulnerable to attack, according to a report released Monday.

The group of five researchers found the security vulnerabilities in netmask, an open source library used in a staggering 270,000 software projects. According to the report, the flaws open the door to a wide range of malicious attacks that could enable attackers to ferry malicious code into a protected network, or siphon sensitive data out of one.

Exploitable Flaw in NPM Private IP App Lurks Everywhere, Anywhere

Among the attacks enabled by the flaw are so-called server-side request forgeries (SSRF), as well as remote file inclusion, local file inclusion and more, the researcher called Sick Codes told The Security Ledger. Work to discover the extent of the flaws continues. The researchers have received a preliminary vulnerability ID for the flaw, CVE-2021-28918.

Even worse, the flaws appear the stretch far beyond a single open source module, affecting a wide range of open source development languages, researchers say.

Work on one vulnerable open source module uncovers another

In addition to Sick Codes, the researchers conducting the investigation are Victor Viale (@koroeskohr), Kelly Kaoudis (@kaoudis), John Jackson (@johnjhacking) and Nick Sahler (@tensor_bodega).

According to Sick Codes, the vulnerability was discovered while doing work to fix another vulnerability in a widely used NPM library known as Private IP. That module, which was also widely used by open source developers, enables applications to block request forgery attacks by filtering out attempts to access private IP4 addresses and other restricted IP4 address ranges, as defined by ARIN. In a report published in November, researchers revealed that the Private IP module didn’t work very well and was susceptible to being bypassed using SSRF attacks against top tier applications.

Spotlight Podcast: Security Automation is (and isn’t) the Future of Infosec

SSRF attacks allow malicious actors to abuse functionality on a server: reading data from internal resources or modifying the code running on the server. Private-ip was created to help application developers spot and block such attacks. SSRF is one of the most common forms of attack on web applications according to OWASP.

The researchers working to fix the Private IP flaw turned to netmask, a widely used package that allows developers to evaluate whether a IP address attempting to access an application was inside or outside of a given IPv4 range. Based on an IP address submitted to netmask, the module will return true or false about whether or not the submitted IP address is in the defined “block.”

Opinion: Better Code Won’t Save Developers in the Short Run

The module has a range of other useful features, as well, such as reporting back on how many IPs are inside a given block. And, with no other “dependencies,” netmask seemed like the perfect fit to fix Private IP’s problems.

There’s only one problem: netmask itself was flawed, as the researchers soon discovered. Specifically: the module evaluates certain IP addresses incorrectly: improperly validating so-called “octal strings” rendering IPv4 addresses that contain certain octal strings as integers.

For example, the IP4 address 0177.0.0.1 should be evaluated by netmask as the private IP address 127.0.0.1, as the octal string “0177” translates to the integer “127.” However, netmask evaluates it as a public IPv4 address: 177.0.0.1, simply stripping off the leading zero and reading the remaining parts of the octal string as an integer.

Sample output from the netmask NPM module showing incorrect parsing of the IPv4 address. The flaw could enable a range of attacks on applications using the popular open source module.
Sample output from the netmask NPM module showing incorrect parsing of the IPv4 address. The flaw could enable a range of attacks on applications using the popular open source module. (Image courtesy of Sick Codes.)

And the flaw works both ways. The IP4 address 0127.0.0.01 should be evaluated as the public IP address 87.0.0.1 as the octal string “0127” is the same as the integer “87.” However, netmask reads the address as 127.0.0.1, a trusted, localhost address. Treating an untrusted public IP address as a trusted private IP address opens the door to local- and remote file inclusion (LFI/RFI) attacks, in which a remote authenticated or unauthenticated attacker can bypass packages that rely on netmask to filter IP address blocks.

A Popular Module with a Sterling Pedigree

Netmask is the creation of Olivier Poitrey, an accomplished developer who is the Director of Engineering at Netflix and a co-founder of the firm NextDNS. The module was first released nine years ago and gained prominence around 5 years ago, with version 1.06, which has been downloaded more than 3 million times.

The netmask module currently sees around 3.1 million downloads weekly, though development on netmask appears to have ceased during the last five years, up until the release of version 2.0.0 around 10 days ago, after discovery of the security holes.

Throwing open the doors to hackers

The implications for modules that are using the vulnerable version of netmask are serious. According to Sick Codes, remote attackers can use SSRF attacks to upload malicious files from the public Internet without setting off alarms, because applications relying on netmask would treat a properly configured external IP address as an internal address.

Similarly, attackers could also disguise remote IP addresses local addresses, enabling remote file inclusion (RFI) attacks that could permit web shells or malicious programs to be placed on target networks.

Parsing IPv4 Addresses: Black Magic

Updates to address the flaws in netmask began appearing on March 19 with the release of version 2.0.0. A subsequent update, 2.0.1, was released on Monday. To date, only 6,641 downloads of the updated netmask module have completed, meaning the vast majority of open source projects using it remain vulnerable. Contacted via chat, Poitrey advised netmask users to upgrade to the latest version of the module.

But researchers say much more is to come. The problems identified in netmask are not unique to that module. Researchers have noted previously that textual representation of IPv4 addresses weren’t ever standardized, leading to disparities in how different but equivalent versions of IPv4 addresses (for example: octal strings) are rendered and interpreted by different applications and platforms.

In the case of the netmask flaw, the true culprit ends up being “some unexpected behaviors of the parseInt function in Javascript combined with an oversight on those odd IP notations nobody (uses),” Poitrey told Security Ledger. “Parsing IPs correctly is black magic,” he said. “Those weird notations should just be deprecated, so nobody can exploit them like this.”

More to come

The impact of the flaw will become more clear in the weeks ahead, according to Sick Codes, as more examples of the IPv4 parsing problem are identified and patched in other popular open interpreted languages. “The implications are infinite,” he said.