In the last few years, IBM X-Force has seen an unprecedented increase in requests to build cyber ranges. By cyber ranges, we mean facilities or online spaces that enable team training and exercises of cyberattack responses. Companies understand the need to drill their plans based on real-world conditions and using real tools, attacks and procedures.

What’s driving this increased demand? The increase in remote and hybrid work models emerging from the COVID-19 pandemic has elevated the priority to collaborate and train together as a team with the goal of being prepared for potential incidents.

Another force driving demand for cyber ranges is the rapid growth of high-profile attacks with seven-figure loss events and the public disclosure of attacks, impacting reputation and financial results. Damaging attacks, like data breaches and ransomware, have cemented the criticality of effective incident response to prevent worst-case outcomes and rapidly contain eventual ones.

Once you decide that your cybersecurity team and other actors in your cyberattack response protocols need to practice together, the economics for a dedicated cyber range is compelling. An organization can train many more employees more quickly through a dedicated cyber range.

But before you pull the trigger and order a cyber range, you should make a full evaluation of the pros and cons. The primary con, of course, is that a dedicated cyber range might be oversized for the organization’s long-term needs. You might not use it enough to justify the costs of building and operating an actual range. Alternatively, you might prefer to run cyberattack exercises remotely to more closely simulate the real work environment of your teams.

This post will provide a primer on conducting a graduated cyber range evaluation and help set up processes to think through what type of drilling grounds might be best suited for your team.

Why Build a Cyber Range? Mandatory Training, Certifications and Compliance

The most compelling reason for building a cyber range is that it is one of the best ways to improve the coordination and experience level of your team. Experience and practice enhance teamwork and provide the necessary background for smart decision-making during a real cyberattack. Cyber ranges are one of the best ways to run real attack scenarios and immerse the team in a live response exercise.

An additional reason to have access to a cyber range is that many compliance certifications and insurance policies cite mandatory cyber training of various degrees. These are driven by mandates and compliance standards established by the National Institute of Standards and Technology and the International Organization for Standardization (ISO). With these requirements in place, organizations are compelled to free up budgets for relevant cyber training.

There are different ways to fulfill these training requirements. Per their role in the company, employees can be required to undergo certifications by organizations such as the SANS Institute. Training mandates can also be fulfilled by micro-certifications and online coursework using remote learning and certification platforms, such as Coursera. The decision to avail a company of a cyber range does not always mean building one in-house.

Learn more

A Cyber Training Progression in Stages: From Self-Study to Fully Operational Cyber Ranges

In talking with our customers, we offer them multiple options for cyber range setups, and we advise them to carry out the implementation in stages. Each stage is appropriate for a different level of commitment, activity and desire for a fully immersive cyber range experience.

Stage 1: Self-Training, Certifications and Labs

Stage 1 is blocking and tackling, the bare minimum for competent cybersecurity training. This provides the basics required for continuing education and fulfilling cyber training requirements. Stage 1 can include:

• SANS training course in desired areas of expertise
• Completion of Coursera online self-paced or Massive Open Online Course classes with requisite certification of completion
• Specific class focus, such as reverse engineering malware or network forensics to explain how attackers traverse networks without being detected, etc.

An added part to Stage 1 is holding hands-on labs where participants complete tasks or simulate blue team or red team activities. The labs should focus on outcomes and metrics as much as they focus on completion. Participants should understand whether they are able to efficiently and effectively find indicators of compromise and mitigate attacks, as well as map the primary tactics, techniques and procedures (TTPs) associated with those attack simulations.

Stage 2: Team and Wider-Scale Corporate Exercises

In Stage 2, the more mature companies can escalate to coordinated group exercises that are planned and follow a curriculum. This requires dedicated compute infrastructure or hardware (some organizations choose to do it all from their existing workstations). In these exercises, all stakeholders take the lessons they have learned and bring them together to orchestrate a coordinated response. You may choose to have red teams attempt to infiltrate and go up against blue teams and involve threat intelligence teams and other security staff in the company’s security operations center.

If you want to make this stage a more immersive and realistic experience, you may also choose to include other teams, such as marketing. Bringing in operational technology (OT) teams at this stage is strongly suggested. Many of the most recent ransomware attacks have targeted not just laptops and other IT devices but also OT devices.

Business leaders tend to benefit strongly from witnessing and experiencing immersive coordinated exercises. Giving them insights into what other teams are experiencing and how they need to respond provides invaluable context that comes into play during an actual crisis. The most advanced team cyber response exercises can involve dozens or hundreds of team members and last several days.

Stage 3: The Collaborative Cyber Range With Vendors, Customers and Partners

Coordinating responses for your organization is a great start. But what about those around you — your customers, vendors and partners? The nature of your digital infrastructure, the ubiquitous connection to application programming interfaces, the proliferation of connected devices and the varying types of connections make it critical to coordinate an attack response with your closest third parties.

It’s easy to understand the criticality of an orchestrated response. The world has become more and more connected; the digital links among vendors, customers and partners have grown. An organization can have hundreds of third-party connections at a time. This has increased the attack surface and made supply chain attacks a preferred tactic with cyber criminals and nation-state actors alike. Supply chain attacks can be hard to detect because they come through a trusted intermediary. They are also a general-purpose exploit for securing future access, traversing networks and expanding horizontally inside an organization.

With awareness of third-party risk management, software supply chain risk growing and attacks in this realm more complex than ever, we are seeing customers asking to take their cyber readiness and exercises to the ecosystem level.

More than a concept to eventually consider, we actually see some companies demanding this participation as a condition of a partnership or becoming a key vendor. Chief information security officers (CISOs) and risk teams want to see beyond the attestations of SOC2 or ISO 2700 and test out the actual capabilities and readiness of their core partners and vendors.

For example, if an organization uses a bank that employs a payment processor that subsequently uses a clearinghouse, all three are tightly knit and have likely established some playbooks on how to work together, how to identify where the chain of interactions encounters a problem or when a breach has occurred. Ultimately, they should know how to contain and stop a cyberattack involving one or more of the three entities. Proactively establishing a risk-aware working relationship and identifying and introducing specific risks for each stakeholder can facilitate a more robust, comprehensive and rapid response in case of an attack. Often this is the point of bringing several parties into the collaborative exercise: to set up the procedures and norms for a collaborative response that’s agile and precise.

Keeping Your Training and Range Lively With Fresh Content and Context

A key part of why we believe organizations are seeking to build their own cyber ranges is the rapid acceleration of attack types and the extent of attacks. Threats that used to emerge over the course of months now emerge in weeks or days. CISOs and risk management leaders recognize this and understand that there are two key ways to address this shift:

• Increase the frequency of exercises
• Improve the content of exercises to keep things fresh over time

With cyber ranges, we can use both static, curriculum-driven content for stage 1 exercises and push evolving content with industry context for those moving to more elaborate exercises. We typically insert lessons and exercises based on attacks that may be happening concurrently with the exercise itself.

Ideally, you want your range to allow for customizable content that can be modified on the fly. This allows a company with a cyber range to load up an exercise on a major attack days after the attack is revealed. That capability makes cyber ranges more relevant and valuable because it enables organizations to speed up their security metabolism and learn faster.

Conclusion: Are You Ready for a Dedicated Cyber Range?

Before you get to the point of thinking about a dedicated cyber range, we highly recommend you work through stage 1 and stage 2 capabilities. At a minimum, you should run a cyber range exercise as a one-off to see how it works for your team and your organization. Most crucially, consider what the utilization rate of your cyber range will be when planning. Ideally, it should be in use most of the time to maximize your investment. Think through whether this is viable for your team and your enterprise before pulling the trigger. As a mitigating factor, think through whether you can use your dedicated cyber range as a pop-up or quick-start cyber operations command center in case of emergency.

After you feel comfortable with the idea of a cyber range and have confirmed its value, consider the positives and negatives of the three types of cyber ranges or outsourcing exercises to a trusted vendor.

• Dedicated on-premise ranges are more expensive to build and maintain but can help teams create in-person chemistry. This has become a more viable option in the past year as more workforces are convening in person again.
• Creating an entirely virtual cyber range prior to the pandemic was not something many organizations were considering. Virtual versions are cheaper to stand up and upgrade and offer more flexibility. However, for some organizations, face-to-face interactions are important.
• A number of customers have come to us requesting hybrid versions with both virtual and in-person components. Hybrid models are flexible and can extend to vendors and partners but are also the more expensive installations.

Having a cyber range at the ready is a fabulous foundation for upping your security metabolism and readiness. Follow a rigorous decision-making process to ensure you get the right kind for your organization and needs. To learn whether a cyber range is right for your organization and how to set up a cyber range program, talk to IBM X-Force Cyber Range Consulting here.

Want to hear directly from the experts? Register for the webinar, Tips and Best Practices for Cyber Ranges: How Your Organization Can Train as First Responders in the Face of an Attack.

The post Everyone Wants to Build a Cyber Range: Should You? appeared first on Security Intelligence.

On September 19, 2022, an 18-year-old cyberattacker known as “teapotuberhacker” (aka TeaPot) allegedly breached the Slack messages of game developer Rockstar Games. Using this access, they pilfered over 90 videos of the upcoming Grand Theft Auto VI game. They then posted those videos on the fan website GTAForums.com. Gamers got an unsanctioned sneak peek of game footage, characters, plot points and other critical details. It was a game developer’s worst nightmare.

In addition, the malicious actor claimed responsibility for a similar security breach affecting ride-sharing company Uber just a week prior. According to reports, they infiltrated the company’s Slack by tricking an employee into granting them access. Then, they spammed the employees with multi-factor authentication (MFA) push notifications until they gained access to internal systems, where they could browse the source code.

Incidents like the Rockstar and Uber hacks should serve as a warning to all CISOs. Proper security must consider the role info-hungry actors and audiences can play when dealing with sensitive information and intellectual property.

Stephanie Carruthers, Chief People Hacker for the X‑Force Red team at IBM Security, broke down how the incident at Uber happened and what helps prevent these types of attacks.

“But We Have MFA”

First, Carruthers believes one potential and even likely scenario is the person targeted at Uber may have been a contractor. The hacker likely purchased stolen credentials belonging to this contractor on the dark web — as an initial step in their social engineering campaign. The attacker likely then used those credentials to log into one of Uber’s systems. However, Uber had multi-factor authentication (MFA) in place, and the attacker was asked to validate their identity multiple times.

According to reports, “TeaPot” contacted the target victim directly with a phone call, pretended to be IT, and asked them to approve the MFA requests. Once they did, the attacker logged in and could access different systems, including Slack and other sensitive areas.

“The key lesson here is that just because you have measures like MFA in place, it doesn’t mean you’re secure or that attacks can’t happen to you,” Carruthers said. “For a very long time, a lot of organizations were saying, ‘Oh, we have MFA, so we’re not worried.’ That’s not a good mindset, as demonstrated in this specific case.”

As part of her role with X-Force, Carruthers conducts social engineering assessments for organizations. She has been doing MFA bypass techniques for clients for several years. “That mindset of having a false sense of security is one of the things I think organizations still aren’t grasping because they think they have the tools in place so that it can’t happen to them.”

Social Engineering Tests Can Help Prevent These Types of Attacks

According to Carruthers, social engineering tests fall into two buckets: remote and onsite. She and her team look at phishing, voice phishing and smishing for remote tests. The onsite piece involves the X-Force team showing up in person and essentially breaking and entering a client’s network. During the testing, the X-Force teams attempt to coerce employees into giving them information that would allow them to breach systems — and take note of those who try to stop them and those who do not.

The team’s remote test focuses on an increasingly popular method: layering the methods together almost like an attack chain. Instead of only conducting a phishing campaign, this adds another step to the mix.

“What we’ll do, just like you saw in this Uber attack, is follow up on the phish with phone calls,” Carruthers said. “Targets will tell us the phish sounded suspicious but then thank us for calling because we have a friendly voice. And they’ll actually comply with what that phishing email requested. But it’s interesting to see attackers starting to layer on social engineering approaches rather than just hoping one of their phishing emails work.”

She explained that the team’s odds of success go up threefold when following up with a phone call. According to IBM’s 2022 X-Force Threat Intelligence Index, the click rate for the average targeted phishing campaign was 17.8%. Targeted phishing campaigns that added phone calls (vishing, or voice phishing) were three times more effective, netting a click from 53.2% of victims.

What Is OSINT — and How It Helps Attackers Succeed

For bad actors, the more intelligence they have on their target, the better. Attackers typically gather intelligence by scraping data readily available from public sources, called open source intelligence (OSINT). Thanks to social media and publicly-documented online activities, attackers can easily profile an organization or employee.

Carruthers says she’s spending more time today doing OSINT than ever before. “Actively getting info on a company is so important because that gives us all of the bits and pieces to build that campaign that’s going to be realistic to our targets,” she said. “We often look for people who have access to more sensitive information, and I wouldn’t be surprised if that person (in the Uber hack) was picked because of the access they had.”

For Carruthers, it’s critical to understand what information is out there about employees and organizations. “That digital footprint could be leveraged against them,” she said. “I can’t tell you how many times clients come back to us saying they couldn’t believe we found all these things. A little piece of information that seems harmless could be the cherry on top of our campaign that makes it look much more realistic.”

Tangible Hack Prevention Strategies

While multi-factor authentication can be bypassed, it is still a critical security tool. However, Carruthers suggests that organizations consider deploying a physical device like a Fido2 token. This option shouldn’t be too difficult to manage for small to medium-sized businesses.

“Next, I recommend using password managers with long, complex master passwords so they can’t be guessed or cracked or anything like that,” she said. “Those are some of the best practices for applications like Slack.”

Of course, no hacking prevention strategies that address social engineering would be complete without security awareness. Carruthers advises organizations to be aware of attacks out in the wild and be ready to address them. “Companies need to actually go through and review what’s included in their current training, and whether it’s addressing the realistic attacks happening today against their organization,” she said.

For example, the training may teach employees not to give their passwords to anyone over the phone. But when an attacker calls, they may not ask for your password. Instead, they may ask you to log in to a website that they control. Organizations will want to ensure their training is always fresh and interactive and that employees stay engaged.

The final piece of advice from Carruthers is for companies to refrain from relying too heavily on security tools. “It’s so easy to say that you can purchase a certain security tool and that you’ll never have to worry about being phished again,” she said.

The key takeaways here are:

• Incorporate physical devices into MFA. This builds a significant roadblock for attackers.
• Try to minimize your digital footprint. Avoid oversharing in public forums like social media.
• Use password managers. This way, employees only need to remember one password.
• Bolster security awareness programs with particular focus on social engineering threats. Far too often, security awareness misses this key element.
• Don’t rely too heavily on security tools. They can only take your security posture so far.

Finally, it’s important to reiterate what Carruthers and the X-Force team continue to prove with their social engineering tests: a false sense of security is counterproductive to preventing attacks. A more effective strategy combines quality security practices with awareness, adaptability and vigilance.

Learn more about X-Force Red penetration testing services here. To schedule a no-cost consult with X-Force, click here.

The post An IBM Hacker Breaks Down High-Profile Attacks appeared first on Security Intelligence.

September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.”

Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a long time since I attempted to do a binary patch diff analysis, so I thought this would be a good bug to do root cause analysis and craft a proof-of-concept (PoC) for a blog post.

On October 21 of last year, I posted an exploit demo and root cause analysis of the bug. Shortly thereafter a blog post and PoC was published by Numen Cyber Labs on the vulnerability, using a different exploitation method than I used in my demo.

In this blog — my follow-up article to my exploit video — I include an in-depth explanation of the reverse engineering of the bug and correct some inaccuracies I found in the Numen Cyber Labs blog.

In the following sections, I cover reverse engineering the patch for CVE-2022-34718, the affected protocols, identifying the bug, and reproducing it. I’ll outline setting up a test environment and write an exploit to trigger the bug and cause a Denial of Service (DoS). Finally, I’ll look at exploit primitives and outline the next steps to turn the primitives into remote code execution (RCE).

Patch Diffing

Microsoft’s advisory does not contain any specific details of the vulnerability except that it is contained in the TCP/IP driver and requires IPsec to be enabled. In order to identify the specific cause of the vulnerability, we’ll compare the patched binary to the pre-patch binary and try to extract the “diff”(erence) using a tool called BinDiff.

I used Winbindex to obtain two versions of tcpip.sys: one right before the patch and one right after, both for the same version of Windows. Getting sequential versions of the binaries is important, as even using versions a few updates apart can introduce noise from differences that are not related to the patch, and cause you to waste time while doing your analysis. Winbindex has made patch analysis easier than ever, as you can obtain any Windows binary beginning from Windows 10. I loaded both of the files in Ghidra, applied the Program Database (pdb) files, and ran auto analysis (checking aggressive instruction finder works best). Afterward, the files can be exported into a BinExport format using the extension BinExport for Ghidra. The files can then be loaded into BinDiff to create a diff and start analyzing their differences:

BinDiff summary comparing the pre- and post-patch binaries

BinDiff works by matching functions in the binaries being compared using various algorithms. In this case there, we have applied function symbol information from Microsoft, so all the functions can be matched by name.

List of matched functions sorted by similarity

Above we see there are only two functions that have a similarity less than 100%. The two functions that were changed by the patch are IppReceiveEsp and Ipv6pReassembleDatagram.

Vulnerability Root Cause Analysis

Previous research shows the Ipv6pReassembleDatagram function handles reassembling Ipv6 fragmented packets.

The function name IppReceiveEsp seems to indicate this function handles the receiving of IPsec ESP packets.

Before diving into the patch, I’ll briefly cover Ipv6 fragmentation and IPsec. Having a general understanding of these packet structures will help when attempting to reverse engineer the patch.

IPv6 Fragmentation:

An IPv6 packet can be divided into fragments with each fragment sent as a separate packet. Once all of the fragments reach the destination, the receiver reassembles them to form the original packet.

The diagram below illustrates the fragmentation:

Illustration of Ipv6 fragmentation

According to the RFC, fragmentation is implemented via an Extension Header called the Fragment header, which has the following format:

Ipv6 Fragment Header format

Where the Next Header field is the type of header present in the fragmented data.

IPsec (ESP):

IPsec is a group of protocols that are used together to set up encrypted connections. It’s often used to set up Virtual Private Networks (VPNs). From the first part of patch analysis, we know the bug is related to the processing of ESP packets, so we’ll focus on the Encapsulating Security Payload (ESP) protocol.

As the name suggests, the ESP protocol encrypts (encapsulates) the contents of a packet. There are two modes: in tunnel mode, a copy of IP header is contained in the encrypted payload, and in transport mode where only the transport layer portion of the packet is encrypted. Like IPv6 fragmentation, ESP is implemented as an extension header. According to the RFC, an ESP packet is formatted as follows:

Top Level Format of an ESP Packet

Where Security Parameters Index (SPI) and Sequence Number fields comprise the ESP extension header, and the fields between and including Payload Data and Next Header are encrypted. The Next Header field describes the header contained in Payload Data.

Now with a primer of Ipv6 Fragmentation and IPsec ESP, we can continue the patch diff analysis by analyzing the two functions we found were patched.

Ipv6pReassembleDatagram

Comparing the side by side of the function graphs, we can see that a single new code block has been introduced into the patched function:

Side-by-side comparison of the pre- and post-patch function graphs of Ipv6ReassembleDatagram

Let’s take a closer look at the block:

New code block in the patched function

The new code block is doing a comparison of two unsigned integers (in registers EAX and EDX) and jumping to a block if one value is less than the other. Let’s take a look at that destination block:

The target code has an unconditional call to the function IppDeleteFromReassemblySet. Taking a guess from the name of this function, this block seems to be for error handling. We can intuit that the new code that was added is some sort of bounds check, and there has been a “goto error” line inserted into the code, if the check fails.

With this bit of insight, we can perform static analysis in a decompiler.

0vercl0ck previously published a blog post doing vulnerability analysis on a different Ipv6 vulnerability and went deep into the reverse engineering of tcpip.sys. From this work and some additional reverse engineering, I was able to fill in structure definitions for the undocumented Packet_t and Reassembly_t objects, as well as identify a couple of crucial local variable assignments.

Decompilation output of Ipv6ReassembleDatagram

In the above code snippet, the pink box surrounds the new code added by the patch. Reassembly->nextheader_offset contains the byte offset of the next_header field in the Ipv6 fragmentation header. The bounds check compares next_header_offset to the length of the header buffer. On line 29, HeaderBufferLen is used to allocate a buffer and on line 35, Reassembly->nextheder_offset is used to index and copy into the allocated buffer.

Because this check was added, we now know there was a condition that allows nextheader_offset to exceed the header buffer length. We’ll move on to the second patched function to seek more answers.

IppReceiveEsp

Looking at the function graph side by side in the BinDiff workspace, we can identify some new code blocks introduced into the patched function:

Side-by-side comparison of the pre- and post-patch function graphs of IppReceiveEsp

The image below shows the decompilation of the function IppReceiveEsp, with a pink box surrounding the new code added by the patch.

Decompilation output of IppReceiveESP

Here, a new check was added to examine the Next Header field of the ESP packet. The Next Header field identifies the header of the decrypted ESP packet. Recall that a Next Header value can correspond to an upper layer protocol (such as TCP or UDP) or an extension header (such as fragmentation header or routing header). If the value in NextHeader is 0, 0x2B, or 0x2C, IppDiscardReceivedPackets is called and the error code is set to STATUS_DATA_NOT_ACCEPTED. These values correspond to IPv6 Hop-by-Hop Option, Routing Header for Ipv6, and Fragment Header for IPv6, respectively.

Referring back to the ESP RFC it states, “In the IPv6 context, ESP is viewed as an end-to-end payload, and thus should appear after hop-by-hop, routing, and fragmentation extension headers.” Now the problem becomes clear. If a header of these types is contained within an ESP payload, it violates the RFC of the protocol, and the packet will be discarded.

Putting It All Together

Now that we have diagnosed the patches in two different functions, we can figure out how they are related. In the first function Ipv6ReassembleDatagram, we determined the fix was for a buffer overflow.

Decompilation output of Ipv6ReassembleDatagram

Recall that the size of the victim buffer is calculated as the size of the extension headers, plus the size of an Ipv6 header (Line 10 above). Now refer back to the patch that was inserted (Line 16). Reassembly->nextheader_offset refers to the offset of the Next Header value of the buffer holding the data for the fragment.

Now refer back to the structure of an ESP packet:

Top Level Format of an ESP Packet

Notice that the Next Header field comes *after* Payload Data. This means that Reassembly->nextheader_offset will include the size of the Payload Data, which is controlled by the size of the data, and can be much greater than the size of the extension headers. The expected location of the Next Header field is inside an extension header or Ipv6 header. In an ESP packet, it is not inside the header, since it is actually contained in the encrypted portion of the packet.

Illustrated root cause of CVE-2022-34718

Now refer back to line 35 of Ipv6ReassembleDatagram, this is where an out of bounds 1 byte write occurs (the size and value of NextHeader).

Reproducing the Bug

We now know the bug can be triggered by sending an IPv6 fragmented datagram via IPsec ESP packets.

The next question to answer: how will the victim be able to decrypt the ESP packets?

To answer this question, I first tried to send packets to a victim containing an ESP Header with junk data and put a breakpoint on to the vulnerable IppReceiveEsp function, to see if the function could be reached. The breakpoint was hit, but the internal function I thought did the decrypting IppReceiveEspNbl, returned an error, so the vulnerable code was never reached. I further reverse engineered IppReceiveEspNbl and worked my way through to find the point of failure. This is where I learned that in order to successfully decrypt an ESP packet, a security association must be established.

A security association consists of a shared state, primarily cryptographic keys and parameters, maintained between two endpoints to secure traffic between them. In simple terms, a security association defines how a host will encrypt/decrypt/authenticate traffic coming from/going to another host. Security associations can be established via the Internet Key Exchange (IKE) or Authenticated IP Protocol. In essence, we need a way to establish a security association with the victim, so that it knows how to decrypt the incoming data from the attacker.

For testing purposes, instead of implementing IKE, I decided to create a security association on the victim manually. This can be done using the Windows Filtering Platform WinAPI (WFP). Numen’s blog post stated that it’s not possible to use WFP for secret key management. However, that is incorrect and by modifying sample code provided by Microsoft, it’s possible to set a symmetric key that the victim will use to decrypt ESP packets coming from the attacker IP.

Exploitation

Now that the victim knows how to decrypt ESP traffic from us (the attacker) we can build malformed encrypted ESP packets using scapy. Using scapy we can send packets at the IP layer. The exploitation process is simple:

CVE-2022-34718 PoC

I create a set of fragmented packets from an ICMPv6 Echo request. Then for each fragment, they are encrypted into an ESP layer before sending.

Primitive

From the root cause analysis diagram pictured above, we know our primitive gives us an out of bounds write at

offset = sizeof(Payload Data) + sizeof(Padding) + sizeof(Padding Length)

The value of the write is controllable via the value of the Next Header field. I set this value on line 36 in my exploit above (0x41 😉).

Denial of Service (DoS)

Corrupting just one byte into a random offset of the NetIoProtocolHeader2 pool (where the target buffer is allocated), usually does not immediately cause a crash. We can reliably crash the target by inserting additional headers within the fragmented message to parse, or by repeatedly pinging the target after corrupting a large portion of the pool.

Limitations to Overcome For RCE

offset is attacker controlled, however according to the ESP RFC, padding is required such that the Integrity Check Value (ICV) field (if present) is aligned on a 4-byte boundary.

Because

sizeof(Padding Length) = sizeof(Next Header) = 1,

sizeof(Payload Data) + sizeof(Padding) + 2 must be 4 byte aligned.

And therefore:

offset = 4n - 1

Where n can be any positive integer, constrained by the fact the payload data and padding must fit within a single packet and is therefore limited by MTU (frame size). This is problematic because it means full pointers cannot be overwritten. This is limiting, but not necessarily prohibitive; we can still overwrite the offset of an address in an object, a size, a reference counter, etc. The possibilities available to us depend on what objects can be sprayed in the kernel pool where the victim headerBuff is allocated.

Heap Grooming Research

The affected kernel pool in WinDbg

The victim out of bounds buffer is allocated in the NetIoProtocolHeader2 pool. The first steps in heap grooming research are: examine the type of objects allocated in this pool, what is contained in them, how they are used, and how the objects are allocated/freed. This will allow us to examine how the write primitive can be used to obtain a leak or build a stronger primitive. We are not necessarily restricted to NetIoProtocolHeader2. However, because the position of the victim out-of-bounds buffer cannot be predicted, and the address of surrounding pools is randomized, targeting other pools seems challenging.

Demo

Watch the demo exploiting CVE-2022-34718 ‘EvilESP’ for DoS below:

Takeaways

When laid out like this, the bug seems pretty simple. However, it took several long days of reverse engineering and learning about various networking stacks and protocols to understand the full picture and write a DoS exploit. Many researchers will say that configuring the setup and understanding the environment is the most time-consuming and tedious part of the process, and this was no exception. I am very glad that I decided to do this short project; I understand Ipv6, IPsec, and fragmentation much better now.

To learn how IBM Security X-Force can help you with offensive security services, schedule a no-cost consult meeting here: IBM X-Force Scheduler.

If you are experiencing cybersecurity issues or an incident, contact X-Force to help: U.S. hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.

References

1. https://www.rfc-editor.org/rfc/rfc8200#section-4.5
2. https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html
3. https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/#diffing-microsoft-patches-in-2021
4. https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
5. https://datatracker.ietf.org/doc/html/rfc4303
6. https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-34718

The post Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP” appeared first on Security Intelligence.

While cloud computing and its many forms (private, public, hybrid cloud or multi-cloud environments) have become ubiquitous with innovation and growth over the past decade, cybercriminals have closely watched the migration and introduced innovations of their own to exploit the platforms. Most of these exploits are based on poor configurations and human error. New IBM Security X-Force data reveals that many cloud-adopting businesses are falling behind on basic security best practices, introducing more risk to their organizations.

Shedding light on the “cracked doors” that cybercriminals are using to compromise cloud environments, the 2022 X-Force Cloud Threat Landscape Report uncovers that vulnerability exploitation, a tried-and-true infection method, remains the most common way to achieve cloud compromise. Gathering insights from X-Force Threat Intelligence data, hundreds of X-Force Red penetration tests, X-Force Incident Response (IR) engagements and data provided by report contributor Intezer, between July 2021 and June 2022, some of the key highlights stemming from the report include:

• Cloud Vulnerabilities are on the Rise — Amid a sixfold increase in new cloud vulnerabilities over the past six years, 26% of cloud compromises that X-Force responded to were caused by attackers exploiting unpatched vulnerabilities, becoming the most common entry point observed. 

• More Access, More Problems — In 99% of pentesting engagements, X-Force Red was able to compromise client cloud environments through users’ excess privileges and permissions. This type of access could allow attackers to pivot and move laterally across a victim environment, increasing the level of impact in the event of an attack.

• Cloud Account Sales Gain Grounds in Dark Web Marketplaces — X-Force observed a 200% increase in cloud accounts now being advertised on the dark web, with remote desktop protocol and compromised credentials being the most popular cloud account sales making rounds on illicit marketplaces.

Download the Report

Unpatched Software: #1 Cause of Cloud Compromise

As the rise of IoT devices drives more and more connections to cloud environments, the larger the potential attack surface becomes introducing critical challenges that many businesses are experiencing like proper vulnerability management. Case in point — the report found that more than a quarter of studied cloud incidents were caused due to known, unpatched vulnerabilities being exploited. While the Log4j vulnerability and a vulnerability in VMware Cloud Director were two of the more commonly leveraged vulnerabilities observed in X-Force engagements, most vulnerabilities observed that were exploited primarily affected the on-premises version of applications, sparing the cloud instances.

As suspected, cloud-related vulnerabilities are increasing at a steady rate, with X-Force observing a 28% rise in new cloud vulnerabilities over the last year alone. With over 3,200 cloud-related vulnerabilities disclosed in total to date, businesses face an uphill battle when it comes to keeping up with the need to update and patch an increasing volume of vulnerable software. In addition to the growing number of cloud-related vulnerabilities, their severity is also rising, made apparent by the uptick in vulnerabilities capable of providing attackers with access to more sensitive and critical data as well as opportunities to carry out more damaging attacks.

These ongoing challenges point to the need for businesses to pressure test their environments and not only identify weaknesses in their environment, like unpatched, exploitable vulnerabilities, but prioritize them based on their severity, to ensure the most efficient risk mitigation.

Excessive Cloud Privileges Aid in Bad Actors’ Lateral Movement

The report also shines a light on another worrisome trend across cloud environments — poor access controls, with 99% of pentesting engagements that X-Force Red conducted succeeding due to users’ excess privileges and permissions. Businesses are allowing users unnecessary levels of access to various applications across their networks, inadvertently creating a stepping stone for attackers to gain a deeper foothold into the victim’s cloud environment.

The trend underlines the need for businesses to shift to zero trust strategies, further mitigating the risk that overly trusting user behaviors introduce. Zero trust strategies enable businesses to put in place appropriate policies and controls to scrutinize connections to the network, whether an application or a user, and iteratively verify their legitimacy. In addition, as organizations evolve their business models to innovate at speed and adapt with ease, it’s essential that they’re properly securing their hybrid, multi-cloud environments. Central to this is modernizing their architectures: not all data requires the same level of control and oversight, so determining the right workloads, to put in the right place for the right reason is important. Not only can this help businesses effectively manage their data, but it enables them to place efficient security controls around it, supported by proper security technologies and resources.

Dark Web Marketplaces Lean Heavier into Cloud Account Sales

With the rise of the cloud comes the rise of cloud accounts being sold on the Dark Web, verified by X-Force observing a 200% rise in the last year alone. Specifically, X-Force identified over 100,000 cloud account ads across Dark Web marketplaces, with some account types being more popular than others. Seventy-six percent of cloud account sales identified were Remote Desktop Protocol (RDP) access accounts, a slight uptick from the year prior. Compromised cloud credentials were also up for sale, accounting for 19% of cloud accounts advertised in the marketplaces X-Force analyzed.

The going price for this type of access is significantly low making these accounts easily attainable to the average bidder. The price for RDP access and compromised credentials average $7.98 and $11.74 respectively. Compromised credentials’ 47% higher selling price is likely due to their ease of use, as well as the fact that postings advertising credentials often include multiple sets of login data, potentially from other services that were stolen along with the cloud credentials, yielding a higher ROI for cybercriminals.

As more compromised cloud accounts pop up across these illicit marketplaces for malicious actors to exploit, it’s important that organizations work toward enforcing more stringent password policies by urging users to regularly update their passwords, as well as implement multifactor authentication (MFA). Businesses should also be leveraging Identity and Access Management tools to reduce reliance on username and password combinations and combat threat actor credential theft.

To read our comprehensive findings and learn about detailed actions organizations can take to protect their cloud environments, review our 2022 X-Force Cloud Security Threat Landscape here.

If you’re interested in signing up for the “Step Inside a Cloud Breach: Threat Intelligence and Best Practices” webinar on Wednesday, September 21, 2022, at 11:00 a.m. ET you can register here.

If you’d like to schedule a consult with IBM Security X-Force visit: www.ibm.com/security/xforce?schedulerform

The post Old Habits Die Hard: New Report Finds Businesses Still Introducing Security Risk into Cloud Environments appeared first on Security Intelligence.

As cybercriminals remain steadfast in their pursuit of unsuspecting ways to infiltrate today’s businesses, a new report by IBM Security X-Force highlights the top tactics of cybercriminals, the open doors users are leaving for them and the burgeoning marketplace for stolen cloud resources on the dark web. The big takeaway from the data is businesses still control their own destiny when it comes to cloud security. Misconfigurations across applications, databases and policies could have stopped two-thirds of breached cloud environments observed by IBM in this year’s report.

IBM’s 2021 X-Force Cloud Security Threat Landscape Report has expanded from the 2020 report with new and more robust data, spanning Q2 2020 through Q2 2021. Data sets we used include dark web analysis, IBM Security X-Force Red penetration testing data, IBM Security Services metrics, X-Force Incident Response analysis and X-Force Threat Intelligence research. This expanded dataset gave us an unprecedented view across the whole technology estate to make connections for improving security. Here are some quick highlights:

• Configure it Out — Two out of three breached cloud environments studied were caused by improperly configured Application Programming Interface (APIs). X-Force incident responders also observed virtual machines with default security settings that were erroneously exposed to the Internet, including misconfigured platforms and insufficiently enforced network controls.
• Rulebreakers Lead to Compromise — X-Force Red found password and policy violations in the vast majority of cloud penetration tests conducted over the past year. The team also observed a significant growth in the severity of vulnerabilities in cloud-deployed applications, while the number of disclosed vulnerabilities in cloud-deployed applications rocketed 150% over the last five years.
• Automatic for the Cybercriminals — With nearly 30,000 compromised cloud accounts for sale at bargain prices on dark web marketplaces and Remote Desktop Protocol accounting for 70% of cloud resources for sale, cybercriminals have turnkey options to further automate their access to cloud environments.
• All Eyes on Ransomware & Cryptomining — Cryptominers and ransomware remain the top dropped malware into cloud environments, accounting for over 50% of detected system compromises, based on the data analyzed.

Download the report

Modernization Is the New Firewall

More and more businesses are recognizing the business value of hybrid cloud and distributing their data across a diverse infrastructure. In fact, the 2021 Cost of a Data Breach Report revealed that breached organizations implementing a primarily public or private cloud approach suffered approximately $1 million more in breach costs than organizations with a hybrid cloud approach.

With businesses seeking heterogeneous environments to distribute their workloads and better control where their most critical data is stored, modernization of those applications is becoming a point of control for security. The report is putting a spotlight on security policies that don’t encompass the cloud, increasing the security risks businesses are facing in disconnected environments. Here are a few examples:

• The Perfect Pivot — As enterprises struggle to monitor and detect cloud threats, cloud environments today. This has contributed to threat actors pivoting from on-premise into cloud environments, making this one of the most frequently observed infection vectors targeting cloud environments — accounting for 23% of incidents IBM responded to in 2020.
• API Exposure — Another top infection vector we identified was improperly configured assets. Two-thirds of studied incidents involved improperly configured APIs. APIs lacking authentication controls can allow anyone, including threat actors, access to potentially sensitive information. On the other side, APIs being granted access to too much data can also result in inadvertent disclosures.

Many businesses don’t have the same level of confidence and expertise when configuring security controls in cloud computing environments compared to on-premise, which leads to a fragmented and more complex security environment that is tough to manage. Organizations need to manage their distributed infrastructure as one single environment to eliminate complexity and achieve better network visibility from cloud to edge and back. By modernizing their mission critical workloads, not only will security teams achieve speedier data recovery, but they will also gain a vastly more holistic pool of insights around threats to their organization that can inform and accelerate their response.

Trust That Attackers Will Succeed & Hold the Line

Evidence is mounting every day that the perimeter has been obliterated and the findings in the report just add to that corpus of data. That is why taking a zero trust approach is growing in popularity and urgency. It removes the element of surprise and allows security teams to get ahead of any lack of preparedness to respond. By applying this framework, organizations can better protect their hybrid cloud infrastructure, enabling them to control all access to their environments and to monitor cloud activity and proper configurations. This way organizations can go on offense with their defense, uncovering risky behaviors and enforcing privacy regulation controls and least privilege access. Here’s some of the evidence derived from the report:

• Powerless Policy — Our research suggests that two-thirds of studied breaches into cloud environments would have likely been prevented by more robust hardening of systems, such as properly implementing security policies and patching.
• Lurking in the Shadows — “Shadow IT”, cloud instances or resources that have not gone through an organization’s official channels, indicate that many organizations aren’t meeting today’s baseline security standards. In fact, X-Force estimates the use of shadow IT contributed to over 50% of studied data exposures.
• Password is “admin 1” — The report illustrates X-Force Red data accumulated over the last year, revealing that the vast majority of the team’s penetration tests into various cloud environments found issues with either passwords or policy adherence.

The recycling use of these attack vectors emphasizes that threat actors are repetitively relying on human error for a way into the organization. It’s imperative that businesses and security teams operate with the assumption of compromise to hold the line.

Dark Web Flea Markets Selling Cloud Access

Cloud resources are providing an excess of corporate footholds to cyber actors, drawing attention to the tens of thousands of cloud accounts available for sale on illicit marketplaces at a bargain. The report reveals that nearly 30,000 compromised cloud accounts are on display on the dark web, with sales offers that range from a few dollars to over $15,000 (depending on geography, amount of credit on the account and level of account access) and enticing refund policies to sway buyers’ purchasing power.

But that’s not the only cloud “tool” for sale on dark web markets with our analysis highlighting that Remote Desktop Protocol (RDP) accounts for more than 70% of cloud resources for sale — a remote access method that greatly exceeds any other vector being marketed. While illicit marketplaces are the optimal shopping grounds for threat actors in need of cloud hacks, concerning us the most is a persistent pattern in which weak security controls and protocols — preventable forms of vulnerability — are repeatedly exploited for illicit access.

To read our comprehensive findings and learn about detailed actions organizations can take to protect their cloud environments, review our 2021 X-Force Cloud Security Threat Landscape here.

Want to hear from an expert? Schedule a consultation with an X-Force team member and register for our cloud security webinar to learn more.

The post X-Force Report: No Shortage of Resources Aimed at Hacking Cloud Environments appeared first on Security Intelligence.

As reported in the IBM X-Force Threat Intelligence Index 2020, X-Force research teams operate a network of globally distributed spam honeypots, collecting and analyzing billions of unsolicited email items every year. Analysis of data from our spam traps reveals trending tactics that attackers are utilizing in malicious emails, specifically, that threat actors are continuing to target organizations through the exploitation of older Microsoft Word vulnerabilities (CVE-2017-0199 and CVE-2017-11882).

• CVE-2017-0199 was first disclosed and patched in April 2017. It allows an attacker to download and execute a Visual Basic Script containing PowerShell commands after the victim opens a malicious document containing an embedded exploit. Unlike many other Microsoft Word and WordPad exploits, the victim does not need to enable macros or accept any prompts — the document just loads and executes a malicious file of the attacker’s choosing.
• CVE-2017-11882 was first disclosed and patched in November 2017. This vulnerability involves a stack buffer overflow in the Microsoft Equation Editor component of Microsoft Office that allows for remote code execution. Interestingly, the vulnerable component was 17 years old (compiled in 2000) at the time of exploitation and unchanged since its removal in 2018.

These vulnerabilities, which were reported and subsequently issued patches in 2017, are the most frequently used of the top eight vulnerabilities observed in 2019. They were used in nearly 90 percent of malspam messages despite being well-publicized and dated. These findings highlight how delays in patching allow cybercriminals to continue to use old vulnerabilities and still see some success in their attacks.

2 Years and Still Going Strong

In addition to these vulnerabilities’ popularity in malspam, the volume of 2019 network attacks that targeted X-Force-monitored customers while attempting to exploit them was 25 times higher than the combined number of network attacks attempting to exploit similar vulnerabilities that leverage Object Linking and Embedding (OLE).

Our analysts did not observe a commonality regarding the malicious payloads used post-exploitation, which means that using these vulnerabilities is the choice of a wide array of threat actors and not specific to a small number of campaigns or adversarial groups.

Figure 1: Observed usage of top CVEs in 2019 spam emails (Source: IBM X-Force)

Another noteworthy insight from the figure above is that most vulnerabilities commonly used by cybercriminals are older ones. None of the vulnerabilities leveraged in 2019 were disclosed last year and only one was disclosed in 2018. The rest go back as far as 2003, further driving home the point that when it comes to malicious cyber activity, what’s old is new and what’s new is old.

The Allure of Older Vulnerabilities

Why would a wide array of threat actors use the same two old and well-known exploits in so many of their attacks? There are a few possible explanations, but the essence of it is they are cheaper, better documented, battle-tested and more likely to lead to legacy systems that are no longer being patched.

First, the exploits are very convenient for an attacker to use in that they don’t require user interaction. Unlike more recent Word vulnerabilities, which require the attacker to convince the user to enable macros, the exploits for these particular vulnerabilities automatically execute when the document is opened. This can help reduce the chance of arousing user suspicions and, accordingly, increase the rate of success.

Second, since so many different actors use these vulnerabilities, it can complicate attribution, as their widespread usage makes associating them with any particular individual or group difficult.

For example, IBM researchers recently observed threat actors leveraging these CVEs and using a variant of the X-Agent malware, which was historically associated with a threat actor known to IBM as ITG05 (also known as APT28). That threat group has been attributed to Russia’s Main Intelligence Directorate. But while they were being used by highly sophisticated threat actors, these vulnerabilities were also leveraged by low-end spammers dropping commodity malware through massive email campaigns.

The reuse of common exploits is a convenient way to muddy threat actor attribution, especially for groups that wish to remain anonymous in their operations. It can allow threat actors to hide among a large volume of activity, obfuscating their actions.

The third and perhaps most likely reason for the continued use of these vulnerabilities is the simple ease and convenience of generating documents that can exploit them. Because these types of documents are essential to the day-to-day operations of many target organizations, they are often not blocked by enterprise email filters. As a final bonus to threat actors, they are also some of the cheapest exploits cybercriminals can buy.

X-Force’s dark web research of underground forums highlights multiple offerings of free document builders that leverage each of these vulnerabilities. Our team also identified free YouTube videos focused on each vulnerability, illustrating how an attacker can generate a document to exploit these issues.

Figure 2: YouTube videos detailing how to generate documents exploiting CVEs 2017-0199, 2017-11882 (Source: IBM X-Force)

One should keep in mind that successful exploitation of older vulnerabilities is more likely to happen on older, unpatched operating systems (OSs) and legacy systems where OS end-of-life means that no new patches are even available. These kinds of systems are most likely used by organizations that can’t patch due to other issues or priorities. While there are many reasons that can contribute to the decision to defer patching, that decision is never a good one in the long run.

What Can Companies Do With This Sort of Information?

Older vulnerabilities are clearly not going away any time soon, so organizations need to be prepared to defend against their attempted exploitation. IBM X-Force Incident Response and Intelligence Services (IRIS) has the following tips for organizations to better protect themselves:

• Asset management is an ongoing process that should be top of mind for risk management. Part of this process is continually assessing risk to critical systems and considering the consequences of not patching them. Reassess the risks and consider patching and updating operating systems as soon as possible. Reality check: Windows 7’s end-of-life took place on January 14, 2020. Is your organization ready to move to an updated OS?
• On the application level, ensure that patches for productivity suites — especially Microsoft software — are applied as soon as they become available.
• Monitor the organization’s environment for PowerShell callouts that may be attempting to download and execute malicious payloads.
• Continue user education on the risks of opening attachments from unknown sources, as vulnerabilities like these do not require any user interaction beyond opening to cause harm.
• Scope and engage in a vulnerability management program to determine if older vulnerabilities are exposing your environment to exploitation by an attacker.

Download the latest X-Force Threat Intelligence Index

The post What’s Old Is New, What’s New Is Old: Aged Vulnerabilities Still in Use in Attacks Today appeared first on Security Intelligence.

IBM X-Force researchers have discovered a new campaign targeting organizations with fake business emails that deliver NetWire remote-access Trojan (RAT) variants.

The RAT is hidden inside an IMG file, which is a file extension used by disk imaging software. Since many attachments can be automatically blocked by email security controls, spammers often carefully choose the type of file extensions they use in malspam messages, and shuffle the types of files they conceal malware in. X-Force’s analysis shows that emails delivered by the NetWire RAT in this campaign are being sent from a small number of unique senders supposedly located in Germany.

The NetWire RAT is a malicious tool that emerged in the wild in 2012. This multi-platform malware has since undergone various upgrade cycles and was detected in different types of attacks that range from cybercrime endeavors by Nigerian scammers to advanced persistent threat (APT) attacks. The NetWire RAT is a commercial offering that can be easily purchased on Dark Web markets, which means that it can be used by just about any threat actor.

This isn’t the first time NetWire is being delivered in fake business communications. In a previous campaign launched in September 2019, its operators sent booby-trapped fake PDF files to potential victims, indicating it was a commercial invoice. The actual file was an executable that installed the NetWire RAT as soon as the file was clicked.

Extracting a RAT

In one of the samples we looked into, an IMG file named “Sales_Quotation_SQUO00001760.img.” was a way for the attackers to archive the malware until the file was clicked open. Once opened, it extracted an executable: the NetWire RAT.

Immediately after this initial execution, the malware established persistence via a scheduled task, a common tactic to many malware developers. Scheduled tasks enable the malware to keep checking that it’s active or relaunch itself in a recurring fashion.

Additionally, registry keys are created to store the command-and-control (C&C) server’s IP address and save data used by the malware to operate on the infected device. Communication with the C&C server is performed over TCP port 3012.

What’s the NetWire RAT Up To?

Since this malware can be used by any group with any motivation, attribution is rather futile. What we did want to figure out was what the NetWire RAT campaign we detected was after this time.

Looking at some unencrypted strings found in memory, we identified a series of strings written in a foreign language, which appears to be Indonesian. Below is a screenshot from Google Translate showing a rough translation of the various identified strings. Many of these terms either relate to a login prompt, payment options, donations or the term “afterlife savings”:

Figure 1: Translated malware strings from recent NetWire RAT campaign

This term may relate to permanent life insurance for retirement purposes offered in some parts of the world.

From the overall look of it, this campaign is financially motivated and most likely being carried out by local fraudsters looking to rob account owners in various ways. Although we have not seen the complete post-infection flow, it may be followed up by a 419-type scam, or might also include social engineering or phishing pages to lure the victim to enter their banking credentials and enable the attackers to take over their accounts.

Recent campaigns in the wild show that the NetWire RAT is not the only malware being delivered via disk imaging file extensions. This was somewhat of a trend in late 2019, likely because the same spamming operators were distributing RATs for different threat actors.

Commercial Malware Abounds

Oftentimes, as security professionals, we hear about the larger and more impactful data breaches, ransomware attacks, and destructive campaigns, which are often carried out by sophisticated cybercrime gangs. But while most financially motivated cybercrime is the work of larger, organized crime groups, smaller factions are still very much in business, and they too target businesses to compromise bank accounts and steal money by using commercially available malware year-round.

Indicators of compromise (IoCs) and other information on how to protect networks from the NetWire RAT can be found on IBM X-Force Exchange.

The post New NetWire RAT Campaigns Use IMG Attachments to Deliver Malware Targeting Enterprise Users appeared first on Security Intelligence.